Model-driven engineering (MDE) is a technique employed in various engineering fields such as software, system and data engineering. MDE involves the systematic use of models as primary engineering artifacts. For example, model-driven software development or model-driven business transformation relies on the use of models such as models defined in the Unified Modeling Language (UML). When dealing with business process models for instance, a model merging scenario often arises where two or more models have to be brought together in some way. One scenario for model merging is the improvement of an existing process model by a reference model, where some parts of the existing model should be preserved and others should be replaced. Merging of process models is also required when different models need to be brought into some degree of conformity. A simple example of this is the merging of business process models when companies are subject to acquisitions and mergers. In such situations, processes have to be aligned at the business and IT level, while identifying and preserving differences where appropriate. Another merging scenario arises if two or more different versions of the same model need to be integrated. For example, where models are manipulated in a distributed manner by several modelers, changes made in different models must be consolidated at some point and an integrated, consolidated model created. Here, differences must be analyzed and parts of different copies must be merged into the integrated model.
Existing techniques and tools offer only limited support for process model merging. For example, most existing merging tools rely on existence of a log which records the changes that have been made to a model and thus provides an indication of differences which need to be addressed. Some prior work has proposed use of a comparison, consisting of correspondences between elements of two process models, as a basis for resolving some differences between process models by a model merging activity. For example, a technique for comparing models using different types of correspondences between model elements is disclosed in “Methodology and Tooling to combine an existing legacy business
process model with best-practice industry reference models for Business Transformation”, Jochen Küster et al., IBM Zurich Research Laboratory, Business Integration Technologies Technical Report RZ 3663 IBM Zurich Research Laboratory. This establishes the idea of using different types of correspondences between a model A and a model B: a 1-1 correspondence between two process model elements specifies that the two model elements have the same semantics; a 1-0 correspondence specifies that for a given element in model A no corresponding element in B exists; a 0-1 correspondence is the reverse, specifying that for a model element in B no corresponding one in A exists. “Improving Business Process Models with Reference Models in Business-Driven Development”, J. M. Küster, J. Koehler, K. Ryndina, 2nd Workshop on Business Processes Design (BPD'06), LNCS, Springer-Verlag, September 2006 describes how the existence of a certain type of correspondence can be used to select a suitable merging operation. For example, if a 1-0 correspondence for an element e1 in a process model A exists with regard to a process model B, then an add operation can be used to add the element e1 to process model B or a remove operation can be used for removing element e1 from process model A.
So far, correspondences have been used to identify elements that have been added or removed from a process model. However, there are also other changes that can occur. For example, elements of a process model can be reordered, causing changes to the control or data flow (referred to collectively herein as control flow changes) of a model. Control flow changes are more difficult to detect and also have an influence on addition and removal of elements. Further, existing techniques lack the sophistication required to handle addition and deletion of control action node elements, such as decision, merge, fork and join elements. If addition of such elements is done in isolation then an invalid model can easily be created.